I think we may be butting heads some, and I'm now regretting not doing some of my changes in a new branch. It has been a lot of error handling updates mainly, but also some reorganization. I'll review this one carefully today and do my best to incorporate your changes with mine.

Yeah, I'm using cl-async daily and was a bit lost after pulling recent changes, sorry if I did some duplicate work. The fixes are necessary for https://github.com/ivan4th/cl-mqtt

@ivan4th This problem with pulling BC breaking changes reminded of the message from this article: http://grimoire.ca/git/stop-using-git-pull-to-deploy

Ok, most of the conflicts were in the tests which was an easy fix.

Please be sure to grab the latest cl-libuv as well, I merged in the grovel branch and things seem to be running much smoother now.

Just read your initial comment in more detail. I guess cl-async is having a bit of an identity crisis when handling errors. Please see orthecreedence/blackbird#8.

A recent addition is the restart send-to-eventcb which mimicks the old error handling when :catch-app-errors t is passed. If :catch-app-errors nil is given, all errors bubble up, but libuv "events" are handed directly to the event-cb (things like socket-eof, filesystem-enoent, etc).

So there's a distinction between libuv events (non-zero status codes passed back in a libuv callback) and errors (user-generated errors created outside of cl-async, but possibly in one of its callbacks).

The new error handling system lets all non-cl-async events flow through untouched (the old system would handler-case the error and re-throw), unless :catch-app-errors is given in which case a few things happen:

• if :send-errors-to-eventcb t is given, any user-generated errors are trapped and passed into the eventcb of the operation the error occured in. this mimicks the behavior of the old cl-async, and is on by default
• if :catch-app-errors is a function and :send-errors-to-eventcb is either nil or an event-cb doesnt exist for the given operation, the function given to :catch-app-errors will be used as a global handler for that error
• if :catch-app-errors t is given and :send-errors-to-eventcb is nil, a generic method handle-error will be given the error object.

your input on how this is set up would be great. at this point, things have been changing so much that i'd sooner have a number of somewhat-breaking changes and make things a lot better than be stuck in some of the poor decisions I made in the past.

Also, tcp-connect, tcp-server, tcp-ssl-connect & tcp-ssl-server now detect whether the event-cb is given for the fourth arg and warn the user to use the :event-cb keyword arg instead.